商业产品高效测试之利器
前言
挣钱是每一个公司的目标，为了完成这一目标，几乎在每一个互联网公司都有传说中的一个团队——商业团队，一般情况下他们主要负责在线广告业务，包括广告投放、广告检索、广告策略等系统的开发和维护。而在转转，我就在这样一个从无到有，快速成长的团队中。随着业务的逐渐成熟，对测试方法和工具也有了更高的要求，本篇简单介绍一下商业测试平台目前包含的功能，以及未来的规划。
广告展示简略流程
先来看一下广告展示的简略流程，以及背后提供支持的服务。由下图可以看到涉及到的功能主要有账户、商品、展示、扣费、反作弊等，细分的话账户主要包括注册、绑定、充值等，商品主要包括创建、同步、审核、删除等，展示主要包括创建、修改等，以及既对立又统一的扣费和反作弊。为了配合业务的建设和扩张，作为QA需要同步的开发一些工具，来提高测试效率，缩短测试时间，同时为了满足分模块的独立测试和流程的整体测试，以及线上的监控等，我们开发了商业测试平台，接下来的章节主要介绍“商业测试平台”。
商业测试平台
本平台主要包括四个部分：测试工具集、线上监控、主流程回归、定时调度任务。测试工具集主要为帐号、商品、投放的增删改查，检索结果的判断，扣费链接的生成及结果判断等。线上监控的实现为调用检索接口，然后在抓取对应列表页中的商品，通过对比两者的差异来实现。主流程回归，顾名思义是为了保证需求迭代过程中，不影响主流程的正常，涉及从最开始的商品发布到最终的扣费这一整个流程的校验。商业产品主要展示的列表页中的第一页，如果线上的测试数据没有及时删除的话，会给用户造成不好的体验，同时也会影响收入，为了满足这一要求，创建了一个定时任务负责定时的清除测试帐号创建的垃圾数据，提高用户体验。同时还有线上展示检测的定时任务，可以尽快的发现展示没有出来等情况，尽早的发现问题，帮助团队尽快的解决问题。
为了方便的调用不同环境中的商业服务，我们使用和线上服务相同的架构WF+SCF。WF的主要架构如下图，分为表示层接受页面的请求，做一些入参等的判断；逻辑层主要的功能都在这一层，负责调用对应的SCF服务，处理复杂的结果判断，同时定时任务也处在这一层；最下层是一些基础的类，负责提供必要的数据和配置文件等。
检索校验、线上监控、扣费结果查询等都比较复杂，下面以检索的校验举例，首先调用检索服务得到符合入参的展示集合A，然后通过从数据库中查询展示表得到展示集合，接下来去掉不符合条件的展示，得到展示集合B，对比集合A和集合B，把对比结果输出到页面上。之所以采用这样的检测方法，主要是为了避免“自证清白”——调用检索服务来证明检索服务执行正确，同时也避免了redis等缓存的影响，可以比较客观的校验检索的结果是否正确。
定时任务使用了开源的elastic-job，通过读取定时任务配置文件，来加载多个不同的定时任务，注册到公司统一的Elastic Job管理平台，方便图形化管理。之所以采用这种方式，而不是像以前直接使用linux的crontab来实现，有两点原因：一是与公司接轨，统一技术栈，便于后续的优化和开发；二是为了以后的扩展。
平台的优点
可满足线下和线上测试数据的快速构造，缩短构造数据的时间；
使用WF+SCF架构，方便使用公司内部的工具和平台；
架构清晰，便于扩展；
使用git开发，便于多人协作。
目前的不足
目前还存在执行结果和监控结果没有记录，没有实现结果通知功能；
平台针对性强，通用性不高，无法实现对其他业务线的帮助；
前期粗放式开发，造成整体架构还需要进一步优化。
未来规划
逐步实现结果的记录，监控结果的记录及通知；
增加监控粒度；
测试数据构造的持续优化；
增加解析线上日志获取入参，构造更符合实际情况的测试数据；
增加提示和帮助，降低使用成本，为将来的开发自测提供支持；
实现反作弊策略的完全覆盖；
及时增加工具，适应业务的未来扩张。
名称解释
CPC: Cost Per Click，每产生一次点击所花费的成本
CPM: Cost Per Mille，广告每展现给一千个人所需花费的成本
CPS: Cost Per Sales。CPS是一种以实际销售产品数量来计算广告费用的广告
CTR: Click-Through-Rate, 网络广告的点击到达率，即该广告的点击量除以广告的浏览量。